In order to facilitate the provision of services to user terminals, a mobile network such as a 3G network will often require the establishment of a secure communication channel or “security association” between client terminals (i.e. mobile terminals) and the network-based service nodes which provide the services. The Generic Bootstrapping Architecture (GBA) defined in the 3GPP Technical Specification TS 33.220 V11.1.0 (2011-12) provides a mechanism whereby a client terminal (UE) can be authenticated to a Network Application Function (NAF) (i.e. an Application Server), and secure session keys obtained for use between the client terminal and the NAF. FIG. 1 illustrates schematically an example of the simple network model for the GBA, as described in 3GPP TS 33.220, which comprises a Bootstrapping Server Function (BSF), a Network Authentication Function (NAF), a Subscriber Locator Function (SLF), a Home Subscriber System (HSS) and the User Equipment (UE). Communication between the NAF and the UE takes place over reference point Ua, communication between the NAF and the BSF takes place over reference point Zn, communication between the UE and the BSF takes place over reference point Ub, communication between the BSF and the HSS takes place over reference point Zh and communication between the BSF and the SLF takes place over reference point Dz.
When the UE wishes to contact a NAF and no security association between the UE and the NAF has been established at an earlier stage, the UE may contact the NAF with a request for communication and the request may not include any GBA-related parameters. If the NAF requires the use of a security association obtained by means of the GBA, the NAF may respond to the UE with a bootstrapping initiation message. The UE will then start a bootstrapping procedure with the BSF. The GBA provides a mechanism to bootstrap the Authentication and Key Agreement (AKA) for application security from the 3GPP AKA mechanism described in 3GPP TS 33.102. This mechanism allows a UE to be authenticated to a BSF and to obtain a master key (Ks) and a Bootstrapping Transaction Identifier (B-TID). GBA User Security Settings (GUSS) is a set of all user security settings and is stored in the HSS. During the bootstrapping procedure, the BSF obtains the GUSS from the HSS. The bootstrapping procedure is indicated in FIG. 2 as step 2.1).
The master key Ks is shared between the UE and the BSF, but not with the NAF. Instead, an application specific key Ks_NAF is derived by the UE. The derivation of Ks_NAF is based on Ks and a NAF_ID, whereby the NAF_ID is constructed by a concatenation of a Fully Qualified Domain Name (FQDN) of the NAF and a security protocol identifier of reference point Ua. The derivation of Ks_NAF is described in 3GPP TS 33.220 and indicated in FIG. 2 as step 2.2).
The UE then supplies the B_TID to the NAF over reference point Ua in an application request. This step is indicated in FIG. 2 as step 2.3). After receipt of the application request at the NAF, the NAF determines the NAF_ID and verifies that the user is authorized to use the NAF_ID, as indicated by step 2.4.1 in FIG. 2. The NAF then sends an authentication request including the B-TID and the NAF_ID to the BSF, as indicated by step 2.4.2 in FIG. 2.
On receipt of the authentication request, the BSF looks up the master key Ks using the B-TID and the BSF derives the application specific key Ks_NAF based on Ks and the NAF_ID supplied by the NAF. This step is illustrated as step 2.5) in FIG. 2. The BSF sends an authentication answer including the Ks_NAF back to the NAF, as indicated by step 2.6) in FIG. 2. The BSF may also include other information, such as the bootstrapping time and the lifetime of the key, in the authentication answer to the NAF. If the key identified by the B_TID is not available at the BSF, the BSF will indicate this in a reply to the NAF and the NAF will then send a bootstrapping renegotiation request to the UE.
The NAF and the UE now both know the value of Ks_NAF and they can use that key to protect communication (step 2.7) between the NAF and the UE over reference point Ua.
The derivation of the application specific key Ks_NAF is based on the NAF_ID of the NAF and the NAF_ID is in turn based on the FQDN of the NAF. A particular FQDN uniquely identifies a NAF. The Ks_NAF derived at the UE will be the same as the Ks_NAF derived at the BSF if one of the following three situations occurs. First, the NAF has only one FQDN. Second, the NAF has multiple FQDNs, and each FQDN is tied to a separate IP address. The NAF may determine which FQDN was used by the UE for key derivation by analyzing the destination IP of the incoming request. Third, the NAF has multiple FQDNs, and the UE may include the FQDN that was used for key derivation in its request (e.g. in the Host header of an HTTP request). This third situation could be the case when the NAF has only one IP address but multiple FQDNs. Therefore, the NAF needs to know which FQDN was used by the UE so that it can obtain the correct Ks_NAF from the BSF. The NAF then validates the FQDN and sends this FQDN to the BSF.
In some cases, it is desirable to divide one physical NAF node into several logical NAFs serving different sets of users. For example, a service provider that deploys a single NAF node which is accessible from several enterprise networks may want to ensure that users from different enterprises cannot interfere with each other. There are several ways of accomplishing such a separation, but one that is particularly convenient is to assign a separate FQDN to each enterprise (e.g., naf.enterpriseX.com) and to use the multiple FQDNs to distinguish between users. In order for the use of a particular FQDN from the larger set of FQDNs to be secure however, the NAF must verify that a user is authorized to use a particular FQDN. Authorisation of a user requires the maintenance of a user database at the NAF or requires the enterprise name to be incorporated in the user ID.
There are also other scenarios where the need for multiple FQDNs might arise. A NAF could, for example, be known under a first FQDN when the NAF is accessed from an internal network and be known under a second FQDN when the NAF is accessed from the public Internet.
The storing of multiple FQDNs in the NAF and associating the multiple FQDNs with different sets of users quickly becomes an administrative burden. The problem becomes even worse when there are multiple NAFs to maintain and when FQDNs and users change quickly.